개요

#192

PR 유형

어떤 변경 사항이 있나요?

• 새로운 기능 추가
• 버그 수정
• CSS 등 사용자 UI 디자인 변경
• 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
• 코드 리팩토링
• 주석 추가 및 수정
• 문서 수정
• 테스트 추가, 테스트 리팩토링
• 빌드 부분 혹은 패키지 매니저 수정
• 파일 혹은 폴더명 수정
• 파일 혹은 폴더 삭제

작업 내용

계층간 역할 분리 및 데이터 전달 방식 획일화

1. 계층 구조

• Gateway Layer (GatewayGateway)

  • WebSocket 연결의 진입점
  • 클라이언트의 이벤트를 수신하고 응답을 전송
  • 실시간 통신을 담당

• Service Layer (GatewayService)

  • Gateway와 Game Service 사이의 중간 계층
  • 데이터 변환과 비즈니스 로직의 조정 역할
  • api에 맞게 클라이언트 응답 포맷팅 담당

• Domain Layer (GameService)

  • 핵심 게임 로직 구현
  • 게임 상태 관리
  • 실제 비즈니스 규칙 처리
  • 예외처리

2. 데이터 흐름

Client <-> GatewayGateway <- response-> GatewayService <-GameState-> GameService

• response

  • 각 api에 맞는 interface를 명시해놓고 그에 맞게 가공된 데이터
  • api가 변경된다면 response 인터페이스와 GatewayService 만 보면 됨

• GameState

  • 게임의 모든 상태 정보로 GatewayService가 참고하여 Response를 만듬
  • 항상 GameService에서는 GameState만 반환하므로 모든 게임 변화상태는 GameState에 담겨있음
  • 혹시 다른 모듈 혹은 서비스가 게임로직과 상태를 참고하고싶을때 GameState만 보면 되기에 확장에 용이

3. 장점

• 단일 책임 원칙을 잘 준수
• 계층간 의존성이 명확하게 정의됨
• 즉 코드의 논리적구조를 깔끔하게 만들어 기능을 확장하거나 리팩토링할때 버그를 줄이고 시간을 줄일 수 있음.

room 모듈,세션과 game 모듈,세션 통합

• 이전에는 room 세션과 game 세션이 나뉘어있기에 불필요한 세션 데이터 중복등이 발생하거나 획일화 되지 못하는 문제가 있었음
• GamPhase를 'WAITING' | 'SPEAKING' | 'VOTING' | 'GUESSING' 로 단순화

게이트웨이(웹소켓)에서 발생하는 모든에러를 filter를 사용하여 처리하도록 변경

• 일일이 try catch 문 안써줘도 되고 그냥 에러 발생하는 곳에서 throw new WsException() 하면됨

공유사항 to 리뷰어

최대한 모든 상황에 대해 테스트해보고 PR하는거지만 대대적인 리팩토링 이기에 혹시 놓친 버그가 있을 수 있습니다..! (머지후 테스트 필요)

PR Checklist

PR이 다음 요구 사항을 충족하는지 확인하세요.

• 커밋 메시지 컨벤션에 맞게 작성했습니다. Commit message convention 참고 (Ctrl + 클릭하세요.)
• 변경 사항에 대한 테스트를 했습니다.(버그 수정/기능에 대한 테스트).